This is a significant change in how props are handled, and I would not expect this behavior when using shared props. Merging is also handled in the frontend. I understand the idea of merging data from the controller into shared props, but I believe it should be more explicit if it should even be a feature of this package.

One example that might break apps is when you share data for a select dropdown:

Inertia::share('someOptions', Model::query()->someGeneralScope()->get());

But then, in another controller or middleware (e.g., for an admin section), you would overwrite it:

Inertia::render('Dashboard', [
    'someOptions' => Model::query()->moreSpecificScope()->get(),
]);

This is a significant change in how props are handled, and I would not expect this behavior when using shared props. Merging is also handled in the frontend. I understand the idea of merging data from the controller into shared props, but I believe it should be more explicit if it should even be a feature of this package.

Thanks for the feedback!

Personally, I find the example use-case a bit uncommon. It suggests intentionally sharing global props, then overriding or limiting them in controllers. In my experience, the opposite is more typical: global props provide consistent data (like base permissions, such as access to certain modules within the application), and controllers extend them contextually - for example by adding page-specific permissions.

However, I fully agree to your concern. The proposed behavior could be unexpected or unwanted in some scenarios. Making it explicit would definitely help avoid confusion.

If you'd like to I’d be happy to revise the PR. What do you think about the following solutions?

Option 1: mergeShare / deepMergeShare method

This method would handle the deep merging behavior and return the full shared prop array.

Inertia::mergeShare($key, $value);

Inertia::render('Index', Inertia::mergeShare([]));

Option 2: Merge strategy pattern

This introduces an extensible solution. By default the ShallowMergeStrategy could be used to preserve the original behavior, which can be overwritten globally or per call.

It also means the DeepMergeStrategy could be left out of the package, if that’s preferred. Since teams could implement their own strategy as needed.

Inertia::share([], new DeepMergeStrategy);

Inertia::withMergeStrategy(new DeepMergeStrategy)->render('Index', []);

Let me know what you think! I'll be happy to adjust the approach to better fit the direction of the package.